IN THE CLAIMS 

Claims 1, 3, 4, 7, 8, 54, and 78 are amended. All pending claims are reproduced below. 

1 . (Currently amended) A computer-implemented method for the intermediation of real 
time meetings, comprising: 

receiving an indication by a requester system that a requester (R-A) wants to request a 
realtime meeting M-A with a target T-A; 

sending to a decider system (D) a request to conduct a real time meeting M-A; 

queuing the request for the meeting M-A by the decider system; 

receiving by the decider system (D) an availability status of T-A; 

receiving by the decider system (D) an availability status of R-A , where a possible 
availability status includes "not available" ; 

receiving an indication by the requester system that a requester (R-B) wants to request a 
realtime meeting M-B with target T-B, the meeting M-B to be disjoint in time with the meeting 
M-A; and such that one of the parties to M-A (R-A or T-A), known as the 'common party' is also 
the same as one of the parties to M-B (R-B or T-B) and thus there are only three distinct parties, 
the decider D being associated with the common party; 

sending to the decider system (D) a request to conduct a real time meeting M-B; 

queuing the request for the meeting M-B by the decider system, such that requests for at 
least two distinct meetings, disjoint in time are placed in the queue, so that multiple pending real 
time meetings for the common party are in the queue at the same time; 

receiving by the decider system (D) an availability status of target T-B; 

receiving by the decider system (D) an availability status of the requester R-B , where a 
possible availability status includes not available ; 

initiating, by the decider, one of the two meetings M-A and M-B by connecting the 
common party and the other party to that meeting when the common party and that other party 
are mutually available; and 

dequeuing the request for a meeting upon its completion. 

2. (canceled) 
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3. (Currently amended) The method of claim 1, wherein a system of the target T-A is 
polled to determine the target's availability of target T-A . 

4. (Currently amended) The method of claim 1, wherein the system of the target T-A 
sends the target's availability status of target T-A to the decider system. 

5. (Previously presented) The method of claim 1, wherein a system of a party is polled to 
determine the party's availability. 

6. (Previously presented) The method of claim 1, wherein the system of a party sends the 
party's availability status to the decider system. 

7. (Currently amended) The method of claim 1, wherein mutual availability is 
determined by checking the availability of the - request e r and the target one of the target/requester 
pairs T-A/R-A and T-B/R-B . 

8. (Currently amended) The method of claim 1, wherein a request is sent to a plurality of 
targets and mutual availability is determined when the requester and a quorum of all the parties 
one of the plurality of targets is available. 

9. (Withdrawn) A computer-implemented method for the intermediation of realtime 
meetings, comprising: 

receiving, by a target system from a requester system, an indication that a requester R-A 
wants to request a realtime meeting M-A with a target; 

queuing the request for M-A by the target system; 

receiving, by the target, an availability status of the requester R-A; 

receiving, by the target system from a requester system, an indication that a different 
requester R-B wants to request a realtime meeting M-B with the target, the meeting M-B to be 
disjoint in time with the other meeting M-A; 

queuing the requests for M-A and M-B by the target system; 

receiving, by the target, an availability status of the requester R-B; and 

connecting the requester and one of the targets who is available to the requester when 
the requester and the target are mutually available; and 
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dequeuing the request for a meeting upon its completion. 

10. (Canceled) 

11. (Canceled) 

12. (Withdrawn) The method of claim 9, wherein the system of the target sends the 
target's availability status to the requester. 

13. (Withdrawn) The method of claim 9, wherein a system of the requester R-A is 
polled to determine the requester's availability. 

14. (Withdrawn) The method of claim 9, wherein the system of the requester R-A sends 
the requester's availability status to the target. 

15. (Withdrawn) The method of claim 9, wherein mutual availability is determined by 
checking the availability of the requester and the target. 

16. (Withdrawn) The method of claim 9, wherein a request is sent to a plurality of 
targets and mutual availability is determined when the requester and a quorum of the targets are 
available. 

17-27. Cancelled 

28. (Withdrawn) A computer-implemented method for the intermediation of real time 
meetings, comprising: 

receiving an indication that a requester party R-A wants to request a real time meeting M- 
A with a target party T-A; 

receiving an indication that the requester party R-B wants to request a real time meeting 
M-B with a target party T-B, the meeting M-B to be disjoint in time with the other meeting M-A; 

receiving information indicating the availability of the requester party R-A and the target 
party T-A to participate in the real time meeting M-A, the information sent by the requester party 
R-A and the target party T-A and indicating a desire of a human being to take part in a meeting; 

receiving information indicating the availability of the requester party R-B and the target 
party T-B to participate in the real time meeting M-B, the information sent by the requester party 
R-B and the target party and indicating a desire of a human being to take part in a meeting; 
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queuing the requests for meetings M-A and M-B by the requester system, such that at 
least two distinct meetings, disjoint in time, are placed in the queue, and such that one of the 
parties to M-A, known as the 'common party' is also the same as one of the parties to M-B and 
thus there are only 3 rather than 4 distinct parties; 

determining that the common party and one of the non-common parties are mutually 
available to participate in the real time meeting, in response to the received information; 

responsive to the determination that the common party and the non-common party to M- 
A are mutually available to participate in the real time meeting M-A, initiating the real time 
meeting M-A; and 

responsive to the determination that the common party and the non-common party to M- 
B are mutually available to participate in the real time meeting M-B, initiating the real time 
meeting M-B. 

29. (Withdrawn) The method of claim 28, wherein the initiating further comprises 
informing the requester party and one or more target parties that they should initiate 
communication. 

30. (Withdrawn) The method of claim 28, wherein the initiating further comprises 
requesting the requester party and one or more target parties to open a connection. 

3 1 . (Withdrawn) The method of claim 28, wherein the availability of the requester 
party and one or more target parties is determined by checking at least one of: start or end of a 
call; other use of phone; recent activity at computer input devices; conversation near 
microphone; lights turned on/off; weight in chair or on floor; a motion sensor; opening/closing of 
door; spoken commands; computer keyboard/mouse based commands; touchtone commands; 
and scheduled periods of availability. 

32. (Withdrawn) A system for intermediation of real time meetings, comprising: 

a requester system R-A for receiving a request from a requester party to initiate a real 
time meeting M-A with a target party T-A; 

a requester system R-B for receiving a request from a requester party to initiate a real 
time meeting M-B with a target party T-B, the meetings M-A and M-B being disjoint in time, 
and one of the parties, known as the "common party," common to both M-A and M-B; 
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a queue, such that requests for at least two distinct meetings M-A and M-B, disjoint in 

time; 

a first server system associated with the common party's system, the first server system 
for determining availability of the common party and sending the availability of the common 
party; 

a second server system associated with the non-common party in M-A's system, the 
second server system for determining availability of the non-common party in M-A and sending 
the availability of the non-common party in M-A; 

a third server system associated with the non-common party in M-B system, the third 
server system for determining availability of the non-common party in M-B and sending the 
availability of the the non-common party in M-B; and 

a deciding agent in communication with the first server system, the second server system, 
and the third server system, the deciding agent for recording the requests for the real time 
meetings M-A and M-B, for receiving an indication whether each of the three parties are 
available for the respective real time meetings M-A and M-B, for determining whether the 
common party and one or more non-common parties are mutually available for the respective 
real time meetings M-A and M-B, and for initiating one of the real time meetings M-A and M-B 
when the requestor party and the respective target parties T-A and T-B are mutually available. 

33. (Withdrawn) The system of claim 32, wherein any of the party's systems record 
that the system should transmit the status of their associated party to the decider. 

34. (Withdrawn) The system of claim 32, wherein each of the first server system and 
the second server system is further adapted to delete the request for the real time meeting. 

35. (Withdrawn) The system of claim 32, wherein the deciding agent is further 
adapted to communicate to any of the party's systems to cease sending an indication that the 
associated party is available for the real time meeting. 

36. (canceled) 

37. (Withdrawn) The system of claim 32, wherein the deciding agent is further 
adapted to poll the first server system to determine the availability of the common party. 
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38. (Withdrawn) The system of claim 32, wherein the deciding agent is further 
adapted to poll at least one of the second and third server systems to determine the availability of 
the party. 

39. (Withdrawn) The system of claim 32, wherein the decider system is part of the 
first server system associated with the common party, and wherein the decider already knows the 
status of the party for which it is responsible. 

40. (Withdrawn) The system of claim 32, wherein the requester systems are further 
adapted to record the request to conduct the real time meeting. 

41. (Withdrawn) The system of claim 32, wherein the target systems are further 
adapted to reject a request to add one or more target parties to the real time meeting and to 
communicate the rejection to the deciding agent. 

42. (Withdrawn) The system of claim 32, wherein the deciding agent is further 
adapted to receive an indication that one or more parties are available by monitoring the activity 
of the parties. 

43. (Withdrawn) The system of claim 32, wherein the real time meeting M-A is 
conducted using a telephone. 

44. (Withdrawn) The system of claim 32, wherein the real time meeting M-A is 
conducted using Internet telephony. 

45. (Withdrawn) The system of claim 32, wherein the real time meeting M-A is 
specified as a face-to-face meeting M-A. 

46. (Withdrawn) The system of claim 32, wherein the real time meeting M-A is 
specified as a text chat. 

47. (Withdrawn) The system of claim 32, wherein the real time meeting M-A is an 
online collaboration tool. 

48. (Withdrawn) The system of claim 32, wherein the real time meeting M-A is a 
shared application. 
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49. (Withdrawn) The system of claim 32, further comprising the presence on M-A of 
a plurality of non-common parties, and wherein the deciding agent initiates the real time meeting 
when a quorum of all the parties is available. 

50-52. Canceled 

53. (Withdrawn) A computer program product stored on a computer readable 
medium for intermediation of real time meetings, the computer program product comprising: 

program code for receiving an indication that a requester party R-A wants to request a 
real time meeting M-A with a target T-A; 

program code for receiving an indication that a requester party R-B wants to request a 
real time meeting M-B with a target T-B, such that one of the parties to M-A, known as the 
'common party' is also the same as one of the parties to M-B and thus there are only three 
distinct parties, the meetings M-A and M-B being disjoint in time; 

program code means for placing in a queue requests for the two distinct meetings M-A 
and M-B, disjoint in time; 

program code for receiving information indicating the availability of the common party 
and the non-common parties to M-A and M-B to participate in the real time meetings M-A and 
M-B, the information sent by the respective parties and indicating a desire of a human being to 
take part in a meeting; 

program code for determining that the common party and one non-common parties T-A 
and T-B are mutually available to participate in the real time meetings M-A and M-B, in 
response to the received information; and 

program code for initiating respective meetings M-A and M-B, responsive to the 
determination that the common party and at least one of the non-common parties are mutually 
available to participate in the respective real time meetings M-A and M-B. 

54. (Currently amended) The method of claim 1, further comprising displaying the 
availability status of the requester one of the requesters R-A and R-B on the target system, along 
with an indication that the request e r one of the requesters R-A and R-B has requested a meeting. 

55. (Previously Presented) The method of claim 54, wherein the availability status is one 
of in, out, and unknown. 
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56. (Previously Presented) The method of claim 1, further comprising displaying an 
availability status of the target T-A on the requester system, along with an indication that the 
requestor has requested a meeting with the target. 

57. (Previously Presented) The method of claim 56, wherein the availability status is one 
of in, out, and unknown. 

58. (Withdrawn) A user interface displayed on a target system, comprising: 

a display showing an ID of a requesting user who has requested a meeting with 

the target; and 

a display showing an availability status of a requesting user, the availability status 
sent by the requesting user. 

59. (Withdrawn) The user interface of claim 58, wherein the availability status is one of 
in, out, and unknown. 

60. (Withdrawn) The user interface of claim 58 showing an age of the request for a 
meeting. 

61 . (Withdrawn) The user interface of claim 58 showing a priority of the request for a 
meeting. 

62. (Withdrawn) The user interface of claim 58 showing a reason for the requested 
meeting. 

63. (Withdrawn) The user interface of claim 58 showing additional information about the 
requesting user. 

64. (Withdrawn) A user interface displayed on a system of an owning user, comprising: 

a display showing an ID of a requesting user who has requested a meeting with the 
owning user and an availability status of the requesting user, the availability status sent by the 
requesting user; 



2 1 892/03950/DOCS/1 647629.2 



the display further showing an ID of a target user with whom the owning user has 
requested a meeting, and the availability status of the target user sent by the target user. 

65. (Withdrawn) The user interface of claim 64, wherein the availability statuses are one 
of in, out, and unknown. 

66. (Withdrawn) The user interface of claim 64, showing an age of the request for a 
meetings. 

67. (Withdrawn) The user interface of claim 64, showing a priority of the request for a 
meetings. 

68. (Withdrawn) The user interface of claim 64, showing a reason for the requested 
meetings. 

69. (Withdrawn) The user interface of claim 64, showing additional information about 
the requesting user. 

70. (Withdrawn) The user interface of claim 58, wherein the ID of the requesting user 
and the availability status of the requesting user are displayed in a single display box. 

71. (Withdrawn) The user interface of claim 64, wherein the ID of the requesting user 
and the availability status of the requesting user are displayed in a single display box. 

72. (Previously presented) The method of claim 1, wherein the decider system a part of 
the system of the common party for whom it is responsible, and wherein the decider already 
knows the status of the common party for which it is responsible. 
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73. (Previously Presented) The method of claim 1, wherein the decider system chooses 
to activate one of two real time meetings, where the parties for both meetings are available, 
based on at least one of: 

ranking information including manual ranking through a user interface presented to the 
common party; 

priority information provided by either party; 

the order in time in which the requests were made; and 

relationship information about the parties based on party input or past history. 

74. (Previously Presented) The method of claim 1, wherein the decider system chooses 
to activate one of two real time meetings, where the parties for both meetings are available, 
based on ranking information including manual ranking through a user interface presented to the 
common party. 

75. (Previously Presented) The method of claim 1, wherein the decider system chooses 
to activate one of two real time meetings, where the parties for both meetings are available, 
based on priority information provided by either party. 

76. (Previously Presented) The method of claim 1, wherein the decider system chooses 
to activate one of two real time meetings, where the parties for both meetings are available, 
based on the order in time in which the requests were made. 
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77. (Previously Presented) The method of claim 1, wherein the decider system chooses 
to activate one of two real time meetings, where the parties for both meetings are available, 
based on relationship information about the parties based on party input or past history. 

78. (Currently amended) The method of claim 1, wherein a non-common requestors 
requester is party to another, distinct meeting request. 

79. (Previously Presented) The method of claim 1, wherein a non-common target is party 
to another distinct meeting request. 

80. (Previously Presented) The method of claim 1, wherein each of the three systems has 
requested and has pending requests for two or more real-time meetings in the queue. 

8 1 . (Previously Presented) The method of claim 1 , wherein if all parties become 
available at once, only one of the meetings M-A and M-B will occur immediately and the 
other meeting will remain queued. 
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